Circa 2009, the Internet was in a stage of its evolution in which the backbone (routers and servers) was connected to fringe nodes formed primarily by personal computers. At that time, Kevin Ashton (among others) looked ahead to the next stage in the Internet's evolution, which he described as the Internet of Things (“IoT”). In his article, “That ‘Internet of Things’ Thing,” RFID Journal, Jul. 22, 2009, he describes the circa-2009-Internet as almost wholly dependent upon human interaction, i.e., he asserts that nearly all of the data then available on the internet was generated by data-capture/data-creation chains of events each of which included human interaction, e.g., typing, pressing a record button, taking a digital picture, or scanning a bar code. In the evolution of the Internet, such dependence upon human interaction as a link in each chain of data-capture and/or data-generation is a bottleneck. To deal with the bottleneck, Ashton suggested adapting internet-connected computers by providing them with data-capture and/or data-generation capability, thereby eliminating human interaction from a substantial portion of the data-capture/data-creation chains of events.
In the context of the IoT, a thing can be a natural or man-made object to which is assigned a unique ID/address and which is configured with the ability to capture and/or create data and transfer that data over a network. Relative to the IoT, a thing can be, e.g., a person with a heart monitor implant, a farm animal with a biochip transponder, an automobile that has built-in sensors to alert the driver when tire pressure is low, field operation devices that assist fire-fighters in search and rescue, personal biometric monitors woven into clothing that interact with thermostat systems and lighting systems to control HVAC and illumination conditions in a room continuously and imperceptibly, a refrigerator that is “aware” of its suitably tagged contents that can both plan a variety of menus from the food actually present therein and warn users of stale or spoiled food, etc.
In the post-2009 evolution of the Internet towards the IoT, a segment that has experienced major growth is that of small, inexpensive, networked processing devices, distributed at all scales throughout everyday life. Of those, many are configured for everyday/commonplace purposes. For the IoT, the fringe nodes will be comprised substantially of such small devices.
Within the small-device segment, the sub-segment that has the greatest growth potential is embedded, low-power, wireless devices. Networks of such devices are described as comprising the Wireless Embedded Internet (“WET”), which is a subset of IoT. More particularly, the WET includes resource-limited embedded devices, which typically are battery powered, and which are typically connected to the Internet by low-power, low-bandwidth wireless networks (“LoWPANs”).
The BLUETOOTH Special Interest Group devised BLE particularly in consideration of IoT devices and applications which do not rely upon continuous connection(s), but depend on extended battery life. A good example of these devices includes a temperature sensor which intermittently provides temperature readings to a collector device that collects such readings. That is, continuous connection between the sensor and collector is not necessary to obtain, for example, such temperature reading at a discrete point in time.
The BLUETOOTH specification governing operation of BLE devices relates definitional roles to each of the above sensor and collector as peripheral and central, respectively.
In accordance with customary BLE networking operations, a peripheral, such as a sensor above, makes its presence known to any central, such as a collector above, merely by continuously “advertising” its presence. In other words, the peripheral continuously sends beacon advertisement messages for recognition by a central that itself decides whether connection with the recognized peripheral should occur. In a BLE environment, such advertising occurs across three advertising channels, or frequencies, so as to reduce instances of interference among signals sent by multiple peripherals.
Yet, existing within such a BLE environment are several impediments to optimal communication between a peripheral device, such as an end node (EN), and a central device, such as an access point (AP).
An example of such an impediment exists in the form of an uncertainty that a peripheral device may experience in actually knowing why its broadcast advertisement has not been acknowledged by a central device. Specifically, such uncertainty exists due to the peripheral's inability to know whether a central device is in a range enabling receipt of its advertisement, or additionally, whether a central device that is in range is simply overloaded such that it has not had sufficient time or capacity to process the peripheral's advertisement.
Yet a further impediment that exists to an optimal relationship between a peripheral and central is congestion across the advertising channels leading to opportunities for signaling collision and missed advertisements, each of which causes a lack of connection. These failures are prevalent in scenarios in which multiple peripherals are co-located, i.e., disposed in or at a same space within a structure such as a building or other venue in which peripheral and central functionality are required or desired.
A still further impediment to BLE networking exists in the fundamental complexity brought about by the conventional BLE peripheral/central relationship. In this relationship, a mobile peripheral which moves out of range of a central such as a first network access point (AP) to which it had previously connected essentially loses any established relationship that such peripheral made with that first AP. In this case, when the peripheral moves within range of another, second AP, this second AP is not immediately able to know, due to the established relationship of the peripheral with the first AP, whether a connection should be made in view of considerations including network configuration, security and authentication. The only basis for informing the second AP whether connection with the peripheral should occur is information it receives from a coordinating application running on the BLE network and that provides information to APs concerning whether connection should be made with a peripheral as a result of its broadcast advertisement. However, by the time the coordinating application learns of the lost connection with the first AP in the above scenario, a considerable amount of time has elapsed before connection information can be, or is, provided by the coordinating application to the second AP in order to allow it to determine that it should connect with the peripheral. Thus, in these ways, it will be understood that enabling connection with a peripheral moving among several APs is not only complex, but further disadvantages exist insofar as increased connection latency and a higher utilization of backhaul due to necessary information that must flow to and from the coordinating application.
Thus, it would be desirable to provide for one or more optimized BLE networking relationships that address and overcome the aforementioned impediments and disadvantages now associated with the conventional BLE central/peripheral networking relationship discussed above. More specifically, it would be desirable to provide applicability of such optimized BLE relationships in connection with various application environments such as, for example, providing healthcare, improving fitness, improving internet connectivity, improving proximity sensing, improving alert systems, improving jobsite monitoring, improving systems controlling access, improving automation and improving systems and methods for tracking assets to be inventoried and for which location must be determined, whether in a commercial or residential setting, as well as any other application in which a BLE networking protocol is deployed.
In association with such optimization, it would be further desirable to, for example, coordinate the tracking of such assets as those assets are in transit between multiple locations, and, for instance, relative to a final, target destination.
Still further, it would also be desirable to conduct that tracking as efficiently as possible so as to conserve energy while the tracking is to occur, and to also achieve such energy conservation while executing one or more of the otherwise mentioned application environments.